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The challenge of the Compiler Optimization Case Q is to perform local optimizations and instruction 
selection on the graph-based intermediate representation of a compiler. The case is designed to 
compare participating tools regarding their performance. We tackle this task employing the general 
purpose graph rewrite system GrGen.NET ( jwww . grgen . net) . 

1 What is GrGen.NET? 

GrGen.NET is an application domain neutial graph rewrite system, which started as a helper tool for 
compiler construction. It is well suited for solving this challenge due to its origin, thus our solution can 
be seen as a reference, even though the origins were left behind a while ago. The feature highlights 
regarding practical relevance are: 

Fully Featured Meta Model: GrGen.NET uses attributed and typed multigraphs with multiple inher- 
itance on node/edge types. Attributes may be typed with one of several basic types, user defined 
enums, or generic set, map, and array types. 

Expressive Rules, Fast Execution: The expressive and easy to learn rule specification language allows 
straightforward formulation of even complex problems, with an optimized implementation yield- 
ing high execution speed at modest memory consumption. 

Programmed Rule Application: GrGen.NET supports a high-level rule application control language. 
Graph Rewrite Sequences (GRS), offering sequential, logical, iterative and recursive control plus 
variables and storages for the communication of processing locations between rules. 

Graphical Debugging: GrShell, GrGen.NET's command line shell, offers interactive execution of 
rules, visualising together with yComp the current graph and the rewrite process. This way you 
can see what the graph looks like at a given step of a complex transformation and develop the next 
step accordingly. Or you can debug your rules and sequences. 

Extensive User Manual: The GrGen.NET User Manual HI guides you through the various features 
of GrGen.NET, including a step-by-step example for a quick start. 

2 Constant Folding 

The first task is to perform constant folding. Constant folding transforms operations which have only 
Const operands into a Const itself, e.g. to transform 1+2 into 3. This is a local optimization requiring 
only rules referencing local graph context. 
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2.1 Driver and Data Flow 



Constant folding is carried out from the driver sequence given in Figure 1 which performs inside a main 
loop in each step i) first constant folding along data flow with a wavefront algorithm, and then ii) control 
flow folding together with clean-up tasks. 

Graph rewrite sequences are the rule application control language of GrGen. The most fundamental 
operation is a rule application denoted by the rule name, with parameters given in parenthesis, and 
optionally an assignment of output values to variables (given in parenthesis, too). By using all bracketing 
[r] we execute the rule r for all matches in the host graph. The then-right operator ; > executes the left 
sequence and then the right sequence, returning as result of execution the result of the execution of 
the right sequence. The potential results of sequence execution are success equaling true and failure 
equaling false; a rule which matches (at least once) counts as success. With the postfix star * we iterate 
the preceding sequence as long as it succeeds. The result of a star iteration is always success, in contrast 
to the plus + postfix which requires the preceding sequence to match at least once in order to succeed; so 
a sequence of rules with plus postfixes linked by strict disjunction operators I succeeds (true) if one of 
the rules matches. Conjunction & is available as well, so are the lazy versions && and I I of the operators 
not executing the right sequence in case the result of the left sequence already determines the outcome. 



The prefix exclamation mark operator negates the result of sequence execution, in [Figure T we negate 



the value from variable isEmpty. The backslashes \ allow to concatenate multiple lines into one. 



xgrs now : set <FirmNode >= se t < FirmNode >{} ;> next : s et <FirmNode >= set <FirmNode >{]■ ; >\ 
( [ colle ctConstUsers ( dummy , now)] ; >\ 

( wavefront (now , next) ;> now.clearO ;> tmp=now ;> now=next\ 

;> next=tmp ;> i sEmpty=now . empty ( ) ;> lisEmpty)* ; >\ 
[foldAssoci at i ve AndCommut at i ve ] ; >\ 
(foldCond+ I removeUnreachablePhiOperand+ |\ 

removeUnr eachableBlock+ I removeUnreachableNode +) * ; >\ 
f ixEdgePos it ion * ; >\ 

( mergeConst s + I removeUnusedNode+ I mergeBlocks +) \ 



Figure 1 : Driver sequence for constant folding. 



In the driver sequence two empty storage sets are created initially for the wavefront algorithm: now 
which will contain the users of constant nodes which are visited in this step and next which will contain 
the users of constant nodes which will be visited in the next step. Then the main loop is entered. There 
the rule collectConstUsers is executed on all available matches, collecting all users of Const nodes 
available in the graph into the storage set now (the dummy variable was never assigned and the collect- 
ConstUsers rule was specified to search for a valid entity if the first parameter is undefined). This is the 
initial stone thrown into the water of our program graph. From it on a wavefront is iterated following the 
data flow edges until it comes to a halt because no new constants were created anymore. A wavefront 
step is encapsulated in the subsequence wavefront given in Figure 2 it visits all operations of its first 
argument, and adds the operations which are users of the constants it created newly with constant folding 
into the set given as its second argument. After this subsequence was called on the now argument the 
now and next sets are swapped (the set referenced by now is cleared, now is assigned the set referenced 
by the next, and next is assigned the empty set previously pointed to by now). The wavefront iteration 
is stopped when the now set of the next iteration step is empty. 

A wavefront step defined by the subsequence given in Figure 2 iterates with a for loop over the users of 
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def wavefront(constUsersNow:set <FirmNode > , \ 

constUsersNext : set <FirmNode >) -fX 

f or{\ 

cu:FirmNode in constUsersNow ; \ 

( (c) = f oldNot (cu) II (c) = f oldBinary (cu) ||\ 

(c)=f oldPhi (cu) & falseX 
)\ 

&& [ colle ct ConstUser s ( c , constUsersNext )] \ 
y ;> cons tUs ersNow . clear () \ 

> 



Figure 2: Wavefront step for constant folding. 



constants contained in the storage set parameter constUsersNow, binding them to an iteration variable 
cu of type FirmNode. This constant is used as input to the rules f oldNot, f oldBinary and f oldPhi 
really doing the folding in case all of the arguments to the operations they handle are constant. They 
return the newly created constant by folding, the rule collectConstUsers then adds all users of this 
constant to the constUsersNext storage set. 

Before we take a closer look at the rules, let us start with a short introduction into the syntax of the 
rule language: Rules in GrGen consist of a pattern part specifying the graph pattern to match and a nested 
rewrite part specifying the changes to be made. The pattern part is built up of node and edge declarations 
or references with an intuitive syntax: Nodes are declared by n : t, where n is an optional node identifier, 
and t its type. An edge e with source x and target y is declared by x -e : t-> y, whereas — > introduces 
an anonymous edge of type Edge. Nodes and edges are referenced outside their declaration by n and 
-e->, respectively. Attribute conditions can be given within if -clauses. 

The rewrite part is specified by a replace or modify block nested within the rule. With replace- 
mode, graph elements which are referenced within the replace-block are kept, graph elements declared in 
the replace-block are created, and graph elements declared in the pattern, not referenced in the replace- 
part are deleted. With modif y-mode, all graph elements are kept, unless they are specified to be deleted 
within a delete () -statement. Attribute recalculations can be given within an eval-statement. In addi- 
tion to rewriting, GrGen supports relabeling, we prefer to call it retyping though. Retyping is specified 
with the syntax y : t<x>: this defines y to be a retyped version of the original node x, retyped to the new 
type t; for edges the syntax is -y : t<x>->. 

These and the language elements we introduce later on are described in more detail in our solution 
of the Hello World case [3J, and especially in the extensive GrGen.NET user manual [IJ. 

[Figure 4 shows the constant folding rule for Binary operations. It takes the node with the Const 
operand as parameter and returns the folded Const. The rule matches both Const operands and has an 
alternative statement that contains one case for each binary operation. Within the cases the value of 
the new Const is computed. In almost all cases the computation is as simple as in the f oldAdd case. 
The only exception is the f oldCmp case that also needs to consider the relation of the Cmp to compute 
the resulting value of the Const. Finally, at the end of the rule execution, the exec statement relinks the 
users of the Binary to the newly created Const and deletes the Binary from the graph (by executing the 
given sequence). The constant folding for unary Not nodes is straight forward and not further discussed; 
n-ary Phi nodes are of interest again. Figure 5 shows the corresponding rule. It first matches the Phi 
node and one Const operand and then iteratively edges to the same operand and to the Phi itself. If this 
covers all edges we can replace the Phi with the Const operand. 
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2.2 Control Flow and Cleanup 



Let us mentally return to the driver sequence in Figure 1 after the wavefront which folded alongside 



data flow has collapsed, execution continues with folding condition nodes at the interface of data flow to 
control flow and with folding control flow proper (jumps and blocks). In addition there are some clean 
up task left to be executed. If no control flow was folded leading to further data flow folding possibilities, 
the main loop is left. 

The rule shown in Figure 6| is responsible for folding Conditional jumps. Depending on the value of 



the constant, either the edge of type True gets deleted and the edge of type False retyped to an edge 
of type Controlf low, or the edge of type False gets deleted and the edge of type True retyped to an 
edge of type Controlf low. Since there is only one jump target left, we also retype the conditional jump 
to a simple jump of type Jmp. Due to the folding of condition jumps, there may be unreachable blocks 



which can be deleted. We use two rules to remove unreachable code: the rule shown in Figure 7 deletes 



unreachable Blocks, the rule shown in Figure 8 deletes nodes without a Block. Furthermore, we also 



need to adapt Phi nodes if they have an operand without a Controlf low counterpart in the Block. Fig 



ure 9 shows the corresponding rule that matches a Phi and deletes an operand that has no Controlf low 
counterpart. After the deletion we fix the position of all edges using the f ixEdgePosition rule. 

The solution contains two rules removeUnusedNode and mergeBlocks that simplify the graph. The 
first rule removes a node that is not used, i.e. a node which has no incoming edges. This rule is similar to 
the removeUnreachableBlock rule. If there is a Block blockl with only one outgoing edge of type 
Controlf low and this edge leads to a node of type Jmp contained in Block block2, then we remove 
the Jmp and merge blockl and block2 with the second rule. This rule is able to remove the chain of 
"empty" Blocks that occurs in the running example of the case description. 

The verifier mentioned in the case descpription was implemented with the tests in Verifier, gri, 
called from a subsequence verify defined in Verifier . grsi; the subsequence is used with the state- 
ment validate xgrs verify before and after the transformations checking the integrity of the graph. 

2.3 Folding More Constants 



Figure 10 shows a rule that folds constants for the term {x*c\)*c2 where * is a associative and commu- 
tative operation. This rule enables us to solve the test cases provided by the GReTL solution. In contrast 
to the GReTL rule, this rule does not change the structure of the graph. 



3 Instruction Selection 

The instruction selection task transforms the intermediate representation (IR) into a target-dependent 
representation (TR). It can be considered as some kind of model transformation. The TR supports im- 
mediate instructions, i.e. a Const operand can be encoded within the instruction. Our solution consists 
of one rule per target instruction which means we have at most two rules for each IR operation: one for 
the immediate variant and one for the variant without immediate. 



Before we start matching all immediate operations, we apply the auxiliary rule shown in Figure 1 1 It 
matches commutative operations with a Const operand at position 0, but not at position 1, and then 
exchanges these operands to ensure that the constant operand is at position 1. Thus, the rule ensures 
deterministic behaviour in case of two constant operands. 



Figure 12 shows exemplarily the rule that creates an Addl operation. It retypes the Add to an Targe- 



tAddl, deletes the Dataflow edge to the constant and stores the value of the Const node in the value 
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S grshell OptiniHation .grs 

GrEhell u3.0 <enter "help" for a list of connands> 
inpoi't done after: 538 ns 
graph size after inport : 473152 bytes 
shell inport done after: 31 ns 
shell graph size after import: 479088 bytes 
Nunber of nodes compatible to type "Node": 14 
Number of edges compatible to type "flEdge": 22 
Graph "Default Graph" imported. 
Registered sequence definition for verify 
Registered sequence definition for wayefront 
The graph is valid uith respect to the given sequence. 

I Executing Graph Rewrite Sequence... <CIRL+C for abort J 
now=t> ;> next=i> ;> < Eco llectConstUsers <dunny, now> ] 
> now.clearO ;> tnp=now ;> - . 

pty>[0:«] ;> [foldflssociatii 
lePhiOperandCl:*] ! renoyeUi 
*] ;> f ixEdgePositionlB:*] 
□ cli3[l:«]>[0:«] 

— available conmands are: <n>ext natch, td>etailed step, 
step <u>p, step <o>ut of loop, <r>un, toggle <h>realipD ints , toggle <c>hi 
s, toggle <l>aEy choice, shou <u >ariable3 , print staclt<t)race, <f)ull si 
<a>hGrt <plus Ctrl+C for forced ahort>. 

now={> ;> next=<> ;> < [co llectGonstUsers <dunny, nDW> ] ;> (uauef rDnt<noi 
> now.clearO ;> tnp=nDW ;> nDW=next ;> next=tnp ;> isEnpty=nou . enptyO 
pty>[0:«] ;> [foldflssociatiuefindConmutatiue] ;> <f o IdCond [1 :«] ! reraouel 



awefront<nou 
i=next ;> next=tnp ;> isEnpty=nou . enptyO 
dGonmutatiue] ;> <f o IdCond [1 :«] ! remoucU 
chablcBlockCl:*] ! renoveUnreachableHode [ 
lergeGonsts [1 ! renoueUnusedNodc [1 : ! 



achabl 
^]>[0:| 
rgeBl| 



lePhiOperandCl:*] ! renoueUi 
*] ;> f ixEdgePositiontB:*] 
oclis[l:«]>[0:«] 
Press any key to apply reur 
Press any Itey to continue.. 

now=^> ;> next=<> ;> <[cd 
> now.clearO ;> tnp=nDW ;> 
pty>[0:«] ;> [foldflssociatii 
lePhiOperandCl:*] ! renoueUi 
*] ;> f ixEdgePositiontB:*] 
ocl4s[l:»]>[0:«] 

uauef root (constUsersNou: set <Fi 
constUsersHou; <<fc>-f oldHottcu 



hableBlockCl:*] 
rgeConsts [1 :**] ! 



ucUn 
ellnu: 



tConstUsers<dunny,noM> ] ; > f uaue front <nou, 
i=next ;> next=tnp ;> isEnpty=nou . enptyO ; 
dConmutatiue] ;> <f o IdCond [1 :«] ! reraouelln 
chableBlock[l:*] ! renoueUni-eacliahleHode [1 
lergeConsts [1 :**] ! i-enouellnusedNode [1 : ! 



B achabl 
ergeBl| 



e achabl 
ergeBll 



inNode>,i 



stUs 



>-foldPhifcu> & fals. 
ow.clearO 



>-foldPhifci 



Dw:set<Fir 
DldHot<cu> 
[collec 



Press any key to apply rewrite... 

Press any key to continue 

wauef rent <CDnst UsersNo wise t<Fir 
constUsersHou; <<fc>-f DldHot<cu> 
>-foldPhifcu> & false> [collec 
ow.clearO 

Press any key to apply rewrite... 



<c>-foldCnp<c 



<c>-foldCnp<c 



<c>-foldCnp<c 



sNext:s 



et<FirnHode»: f 
<c>-foldBinarytc 
sNext>]» ;> con 

et<FirnHode»: f 
<c>-foldBinarytc 
sNext>]» ;> con 



et<FirnHode»: f 
<c>-foldBinarytc 
sNext>]» ;> con 




Figure 3: A situation from constant folding 



attribute. Since the other rules for immediate operations are very similar, we omit them here. Instead we 



want to introduce the rule for creating TargetLoads given in Figure 13 Again, we retype the original 
operation to the corresponding target operation. Since Load is a memory operation, we also need to set 
the volatile attribute. 



The instruction selection rules are applied by the sequence shown in Figure 14 The [rule] operator 
matches and rewrites all occurrences of the given rule. Hence, we first create all immediate operations, 
and then the non-immediate operations for the remaining nodes. 



4 Conclusion 

We presented a GrGen solution for both tasks, constant folding as well as instruction selection, covering 
all test cases. The solution employing pure graph rewriting is pretty concise for the constant folding task 
but admittedly less so for the instruction selection task, which requires a good deal of (very simple) 
graph relabeling rules, one rule per operation plus a further rule for the operations with immediate. The 
conciseness could be improved by stepping an abstraction level up by implementing a generator emitting 
GrGen code, which is what we did in [4J and [6i and what we recommend for the classes of applications 
which would lead to repetitive code. 

The debugger included in the GrShell, which allows to execute the sequences step-by-step under user 
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control, was a great help during development of the optimizations. Especially its graph visualizations, 
which are depicted in Figure 3| and in the case description fT\. 

Due to the wavefront algorithm only visiting relevant operations and the core speed of the generated 
code we were able to give a solution with excellent performance. For the largest GReTL test case - 
consisting of 27993 nodes and 55981 edges - the execution speed is 6.3 seconds for constant folding 
and 111 milliseconds for instruction selection. For the largest test shipped with this case - consisting 
of 277529 nodes and 824154 edges - we need 11 seconds for constant folding and 1.2 seconds for 
instruction selection. This is more than one order of magnitude better than the next-closest competitor. 
The measurements were made using Ubuntu 11.04 and Mono 2.6.7 on a Core2Duo E6550 with 2.33 
GHz. The numbers are even better for the SHARE machine(s) hosting the GrGen image (5) at the time 
of writing. 

Our solution does not apply rules in parallel. However, we consider it as a benchmark for parallel 
solutions. Unfortunately, nobody submitted a parallel solution, which was the main purpose of publishing 
the challenge: we were hoping for hints about the potential benefits of parallehzation. So the question 
which speed up can be gained by parallel rule application is still open. 
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rule foldBinary (b : Binary <FirmNod.e >) : (Const) 
{ 

startBlock : StartBlock ; 

b -df : Dataflow -> cO : Const ; 

b -df 1 : Dataf low-> cl : Const ; 

horn ( cO , c 1) ; 

i/{ df . position==0 && df 1 . posit ion==l ; > 



alternative { 
foldAdd { 

ifi t3/peo/(b)==Add; } 



modify { 

eval { c . value = cO . value + cl. value; > 

} 

} 



foldCmp { 

*/"C typeo f (.h')==CmTp ; } 

modify { 
eval { 

c . value = ( 



cmp . 


relation 




Relation : ; 


: TRUE 1 1 


cmp . 


relation 




Relation : : 


: GREATER 


&& 


cO . value 


> 


cl . value 


1 1 


cmp . 


relation 




Relation : : 


: EQUAL 


&Sc 


cO . value 




cl . value 


1 1 


cmp . 


relation 




Relation : : 


: GREATER.EQUAL 


&& 


cO . value 


> = 


cl . value 


1 1 


cmp . 


relation 




Relation : : 


: LESS 


&Sc 


cO . value 


< 


cl . value 


1 1 


cmp . 


relation 




Relation : ; 


; NOT_EQUAL 


&& 


cO . value 


1 = 


cl . value 


1 1 


cmp . 


relation 




Relation : : 


; LESS_EQUAL 


&& 


cO . value 


<= 


cl . value 




? 1 


: 0; 









} 

} 



modify i 

c : Const - startBlockEdge : Dataf low -> startBlock; 

eval { St art BlockEdge . posit ion = -1; ]■ 
exec ( [relinkUser (b , c ) ] ;> deleteNode (b ) ) ; 
returnC.c) ; 

y 

y 



Figure 4: Rule for folding Binary nodes. 
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rule f oldPhi (phi : Phi <FirmNode >) : (Const) 
{ 

startBlock : StartBlock ; 

phi -blockEdge : Dataflow -> block:Block; 
phi -eO : Dataflow -> cO : Const ; 

iterated {. 

phi -e : Dataflow -> cO ; 

modify { 
delete(.e) ; 

} 

} 

iterated {. 

phi -e : Dataflow -> phi; 

modify { 

delete(e) ; 

} 

} 

negative {. 
cO ; 

block ; 

phi -:Dataflow-> : FirmNode ; 

} 

modify { 

de lete (blockEdge , eO); 

c : Const <phi > ; 

c -startBlockEdge : Dataf low-> startBlock; 

eval ■[ 

c . value = cO . value ; 
StartBlockEdge . position = -1; 

} 

returnC.c) ; 

y 

y 



Figure 5: Rule for folding Phi nodes. 
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rule foldCond 
{ 

startBlock : StartBlock ; 

con<i:Cond -blockEdge : Dataflow -> ; 

cond -df : Dataflow -> cO : Const ; 

falseBlock : Block - f alseEdge : False -> cond; 

trueBlock : Block -trueEdge : True -> cond; 

hom ( falseBlock , trueBlock); 

alternative { 
TrueCond { 

if { cO . value == 1 ; } 

modify { 

deleteCf alseEdge) ; 

- jmpEdge : Controlf low < trueEdge >-> ; 

} 

} 

FalseCond { 

if { cO . value ==0; } 

modify { 

<Jelete(trueEdge) ; 

- jmpEdge : Controlf low <f alseEdge >-> ; 

} 

} 

} 

modify { 

deleteCdf 0) ; 
jmp : Jmp <cond > ; 

} 

} 

Figure 6: Rule for folding Cond nodes. 



rule removeUnreachableBlock 
{ 

block : Bio ck\ StartBlock ; 

negative { 

block -cfgEdge : Controlf low->; 

} 

modify { 

deleteCblock) ; 

} 

} 

Figure 7: Rule for removing unreachable Blocks. 
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rule removeUnreachableNode 
{ 

n:FirmNode\Block; 

negative { 

n -blockEdge : Dataflow -> :Block; 

if { blockEdge . position == -1; } 

} 

modify { 

delete(n) ; 

} 

} 

Figure 8: Rule for removing nodes without a Block. 



rule removeUnreachablePhiOperand 
{ 

phi : Phi -blockEdge : Dataflow -> block:Block; 
phi -operandEdge : FirmEdge -> operand : FirmNode ; 

negative { 

block -cf gEdge : Controlf low->; 

if {. cf gEdge . position == operandEdge . position ; } 

} 

modify { 

deleted operandEdge ) ; 

} 

} 



Figure 9: Rule for removing nodes without a Block. 
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rule f oldAssociativeAndCommutative 
{ 

binO : Binary ; 

binO -:Dataflow-> block:Block; 

binO -binEdge : Dataflow -> binl : ti/peo/CbinO ) ; 

binO -constEdge : Dataflow -> cO : Const ; 

binl -:Dataflow-> operand : FirmNode \Block ; 

binl -:Dataflow-> cl : Const ; 

horn ( cO , cl) ; 

if {. binO . associative && binO . commutative ; } 

modify { 

de lete (binEdge , constEdge); 

bin: tj/peo/ ( binO ) ; 

bin -blockEdge : Dataflow -> block; 

bin -lef t : Dataflow -> cO ; 

bin -right : Dataflow -> cl; 

binO -binLeft : Dataflow -> operand; 

binO -binRight : Dataflow -> bin; 

eval { 

blockEdge . position = -1; 
lef t . position = 0; 

right . position = 1; 

binLeft . position = binEdge . position ; 
binRight . position = constEdge . posit ion ; 



Figure 10: Rule for constant folding of associative and commutative operations. 



rule NormalizeConsts 
{ 

bin : Binary ; 

bin - opOEdge : Dataflow -> opO : Const ; 

bin -oplEdge : Dataflow -> opl : FirmNode\Const ; 

if i bin . commutative && opOEdge . position == && oplEdge . position == 1; } 



} 



} 



} 



modify { 
eval { 



opOEdge . position 
oplEdge .position 



1; 
0; 



} 



} 



} 



Figure 1 1 : Rule for normalizing commutative operations with a Const operand. 
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rule ToTargetAddl 

{ 

a : Add -df : Dataflow -> c : Const ; 
if {. df . position = = l ; } 

modify {. 

ta:TargetAddI<a>; 
deleted di) ; 
eval { 

ta. value = c . value ; 

} 

} 

} 

Figure 12: Rule for an Target Addl operation. 



rule ToTargetLoad 
{ 

1 : Load ; 
modify { 

t : TargetLoad <1> ; 

eval {. t. volatile = 1. volatile; } 

} 

} 

Figure 13: Rule for an TargetLoad operation. 



xgrs [NormalizeConst ] 

xgrs [ToTargetLoadI] I [ToTargetStorel] I [ToTargetAddl] l\ 

[ToTargetSubl] I [ToTargetMulI ] I [ToTargetDi vl ] |\ 

[ToTargetModI] 1 [ToTarget Andl ] I [ToTargetOrl] |\ 

[ToTargetEorl] I [ToTargetShll ] I [ToTargetShr I ] |\ 
[ToTargetShrsI] I [ToTargetCmpI ] 



xgrs [ToTarget Jmp] 


1 [ToTargetCond] 


1 [ToTargetLoad] 


l\ 


[ToTarget St ore] 


[ToTargetConst ] I 


[ToTargetSymConst ] 


l\ 


[ToTargetNot ] 


[ToTargetAdd] I 


[ToTargetSub] 


l\ 


[ToTargetMul] 


[ToTargetDiv] 1 


[ToTargetMod] 


l\ 


[ToTarget And] 


[ToTargetOr] I 


[ToTargetEor] 


l\ 


[ToTargetShl] 


[ToTargetShr] I 


[ToTargetShrs] 


l\ 


[ToTargetCmp] 









Figure 14: Extended graph rewrite sequence for instruction selection. 



